* Bump version to 2.22.0 (osi-orionbelt 0.1.1)

Minor rather than patch: sqlglot's floor moved 26 -> 30, so installs pinning
sqlglot 26 cannot take this release, and Python 3.14 is newly supported.

Bumps osi-orionbelt 0.1.0 -> 0.1.1 in the same tag. The PyPI publish workflow
sets skip-existing on that job, so leaving it at 0.1.0 would have skipped the
job silently and shipped the converter fixes (#201, #202) nowhere while the
release still went green.

Release contents (20 commits since v2.21.1, mostly Dependabot):
- Python 3.14 across all three Docker images + CI matrix (#216)
- sqlglot 30 adaptation; pyarrow <26, structlog <27 (#217)
- osi-orionbelt converter roundtrip fidelity + validation robustness (#200,
  #201, #202)

2621 passed, 167 skipped. ruff and mypy clean.

* Fix osi-orionbelt exported __version__ and guard against recurrence

osi-orionbelt was bumped to 0.1.1 in pyproject.toml and uv.lock, but the module
still exported __version__ = "0.1.0", so the published wheel would have
self-reported 0.1.0 while its metadata said 0.1.1.

Root cause: the version-ref sweep grepped for the main package's version
(2.21.1) only, and osi-orionbelt is versioned independently, so its constant was
never in the search.

Adds tests/unit/test_version_consistency.py, which asserts every package's
exported __version__ matches its pyproject version. Verified it fails on the
reintroduced bug, not just passes on the fix. There was no existing release
consistency check to extend.

2623 passed, 167 skipped. ruff and mypy clean.

P2 - CLI silently accepted an authored `label:` that the REST API rejects.
The API enforces the JSON Schema at its ingestion boundary (api/schema_guards.py)
while ModelStore.load_model stays coercion-tolerant for internal callers. The
CLI is also an external boundary but called load_model directly, bypassing the
guard. Add the schema check to the CLI's single load chokepoint (_local._load),
so `obsl compile/execute/describe/...` fail loudly with a clean CliError, the
same way the API returns 422. load_model is left unchanged.

P3 - the public reference (docs/guide/model-format.md) still listed `label` as
an authorable property for dimensions and metrics. Removed both rows; the
DataObject and Measure tables already omit it, and the sections are documented
as "dictionaries keyed by name".

Test gap - test_schema_properties_are_covered_by_manifest only checks schema
subset of manifest, so re-adding `label` to the schema would go unnoticed. Add:
- dimension/measure/metric.label to test_removed_fields_absent_from_schema
- test_authored_label_fails_schema_validation (behavioral, all three types)
- test_compile_rejects_authored_label (CLI boundary, clean error, no traceback)

Refs #201, #202.

P2 (follow-up) - the obml-to-osi conversion path bypassed OBML schema
validation on both external surfaces, so an authored `label:` was silently
coerced away rather than surfaced.

Conversion is advisory-not-blocking by design (the osi-to-obml direction
already validates its OSI input into `input_validation` without failing the
request). Mirror that for obml-to-osi:

- api/routers/convert.py: run advisory OBML input validation and surface it in
  the response `input_validation` field, matching osi-to-obml. Conversion still
  runs; a schema violation is reported, not silently dropped.
- cli/_local.py::convert_obml_to_osi: validate the OBML input and prepend any
  schema issues to the returned warnings, so `obsl convert obml-to-osi` emits
  them instead of succeeding silently.

Tests:
- test_api_convert.py: replaced TestObmlToOsiBackwardCompat (which codified the
  old "input_validation is None" behavior) with TestObmlToOsiInputValidation -
  valid input reports schema_valid, an authored label is surfaced with the
  request still 200 (advisory).
- test_cli.py: convert obml-to-osi with an authored label surfaces the warning,
  exit 0, output still produced.

Refs #201, #202.